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The class framework developed for vertex reconstruction in CMS is described. We emphasize how 
we proceed to develop a flexible, efficient and reliable piece of reconstruction software. We describe 
the decomposition of the algorithms into logical parts, the mathematical toolkit, and the way vertex 
reconstruction integrates into the CMS reconstruction project ORCA. We discuss the tools that we 
have developed for algorithm evaluation and optimization and for code release. 



I. INTRODUCTION 

As many reconstruction problems, vertex recon- 
struction can be decomposed into the following steps: 

• Pattern recognition, or vertex finding. This step 
consists in finding clusters of compatible tracks 
among a set of tracks given on input. The search 
can either be inclusive, like in the search of a 
secondary vertex in a 6-jet, or be guided by the 
a-priori knowledge of the decay channel. 

• Fitting. This step consists in estimating the 
vertex position most compatible with the set of 
tracks given on input, and constraining the mo- 
mentum vector of the tracks using the vertex 
position. 

In high-luminosity experiments, vertex reconstruc- 
tion algorithms must be able to deal with large track 
multiplicities, frequent ambiguities in the separation 
of primary and secondary tracks, and track mis- 
reconstructions leading to biases in the estimated 
track parameters. As an illustration of the difficulty 
to separate primary and secondary tracks, the res- 
olution on the transverse impact parameter of the 
CMS tracker ranges from ~ 100 ^m for tracks with 
pr = 1 GeV/c to ~ 10 /im for tracks with px > 
100 GeV/c [10], while the transverse impact param- 
eter of secondary tracks in 50 GeV 6-jets is on average 
much smaller than 1 mm. 
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Although the algorithmic part of the problem is the 
most difficult to solve, an additional constraint comes 
from the CPU time available online in LHC experi- 
ments. Simulation studies have shown the interest of 
primary vertex finding for online event filtering 0, Q . 
In addition, 6-jet tagging by detecting a secondary ver- 
tex inside the jet cone seems toperfom almost as well 
as impact parameter tagging |5(, and to complement 
this method to some extent. 

For this to be applicable, the CPU time that vertex 
finding takes should be small, O(50 ms) on the proces- 
sors expected in 2007. As vertex finding is often based 
on repeated compatibility checks between tracks and 
fitted vertices, this translates into very strong CPU 
constraints on vertex fitting algorithms as well. 



II. MOTIVATION FOR A FRAMEWORK 

When developing vertex reconstruction code, physi- 
cists face the following issues: 

• The algorithmic problem is complex. The opti- 
mal algorithm cannot be guessed from the start, 
and there will probably be no single optimal al- 
gorithm but several, each optimized for a spe- 
cific task. 

• The mathematics involved is complex, but often 
localized in a few places. Development would be 
made easier by providing a toolkit of mathemat- 
ical classes. 

• Performance evaluation and comparison be- 
tween algorithms is not trivial. Vertex recon- 
struction uses reconstructed tracks as input, and 
features of the vertexing algorithms must be dis- 
entangled from those of the tracking algorithms. 
Criteria to compare Monte Carlo simulated and 
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reconstructed vertices are ill-defined and need to 
be standardized. 

• Finally, the problem is quite generic and decou- 
pled from the detector geometry once tracks are 
given. This makes a good case for providing 
a framework reuseable in other HENP experi- 
ments. 

We have thus decided to develop a flexible frame- 
work in order to ease the development and evaluation 
of algorithms. This is realized within the CMS object- 
oriented reconstruction project ORCA jfj. Section UTTI 
describes the vertex fitting framework. Section IIVI 
deals with the vertex finding framework, with a fo- 
cus on evaluation and optimization tools. Section [V] 
explains the use of a simplified configurable event gen- 
erator for faster code development and release tests. 



III. VERTEX FITTING FRAMEWORK 

The fitted parameters are the solution of a mini- 
mization problem involving the residuals between the 
vertex parameters x and a transformation / of the 
track parameters pi: 

Ming F[x — f(pi)]; i S input tracks. 

Fitting algorithms may differ by the choice of the track 
parametrization, and by the choice of the function F 
to minimize. Each algorithm is a different implemen- 
tation of the abstract VertexFitter class. 

A usual choice for F is the sum of the reduced 
residuals squared, this is the well-known Least Sum 
of Squares, or Least Squares, technique. In this case 
the minimum of F can be expressed explicitely as a 
function of the pi's, which is CPU-effective. This re- 
quires however to linearize the transformation / in the 
vicinity of the true vertex position. 



A. Linearization 

The linearization is performed on demand and 
cached for performance. This is done by instances of 
a concrete class, the LinearizedTrack. Currently we 
use 2 linearizations, corresponding to different track 
approximations: 

• A straight line approximation, and a constant 
track error matrix hypothesis. 

• A helix approximation, and a linear error prop- 
agation using the first derivatives of / with re- 
spect to the track parameters as Jacobians. 

Formally the second approximation is much more pre- 
cise, but in the pr range of interest at the LHC, both 



have negligible contributions to the precision of the 
fitted vertex. 

The LinearizedTrack is also responsible for pro- 
viding the parametrization required by the algorithm. 
All useful parametrizations are supported. We cur- 
rently use (x, y, z) at the point of closest approach to 
the vertex, together with the straight line approxima- 
tion, and (q/pT,0,(j)p,do, z p ) the 5 track parameters 
at the perigee, with the helix approximation. 

Linearization around the true vertex position re- 
quires a first guess of this position. This is provided by 
LinearizationPointFinder algorithms. These com- 
pute the average of the crossing points of N track 
pairs (N = 5 by default). In order to use tracks of 
best precision, the 2 * N tracks of highest pr are se- 
lected. Two implementations are available, one using 
the arithmetic average of the crossing points, and one 
using a Least Median of Squares (LMS) robust aver- 
aging technique 0, H| . 

These algorithms rely on fast computation of the 
points of closest approach of 2 tracks. The system 
of 2 transcendent equations is solved for the running 
coordinates along the tracks using a highly optimized 
Newton iterative method. The maximum CPU time 
required for finding the linearization point is 0.1 ms 
on 1 GHz processors. 

B. Iterative vertex fitting 

Iterations arise naturally when: 

• The linearization point is too far from the fitted 
vertex. 

• The function F has no explicit minimum. This 
is the case in robust fitting techniques. Robust 
estimators can be reformulated as iterative, re- 
weighted Least Squares estimators II] ■ 

• Several vertices are fitted together, account- 
ing for ambiguities in an optimal way In 
such a Multi- Vertex Fit, one LinearizedTrack 
can contribute to several vertices with different 
weights. 

This lead us to the introduction of another con- 
crete component, the VertexTrack. It relates a 
LinearizedTrack to a vertex, and stores the weight 
with which the track contributes to the fit. To 
avoid having to care for the ownership of these ob- 
jects, LinearizedTrack and VertexTrack arc han- 
dled through reference-counting pointers. 

C. Sequential vertex update 

Apart from cases where some hits are shared, tracks 
are uncorrelated. This allows sequential update of 
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the fitted parameters, by adding one track at a time. 
This procedure is faster than a global fit [ljj. The 
VertexUpdator is the component responsible for up- 
dating the fitted parameters with the information of 
1 track. 

To compute the x 2 increment, the VertexUpdator 
uses the VertexTrackCompatibilityEstimator. 
This increment can also be used at vertex find- 
ing to test the compatibility between a track 
and a vertex. The VertexUpdator and the 
VertexTrackCompatibilityEstimator are ab- 
stract and there are 2 implementations, 1 for each 
parametrization. 

The CPU time for track linearization and vertex 
update is < 0.25 ms per track on 1 GHz processors. 



D. Constraining the track momentum vectors 

The momentum vectors of the tracks can also be im- 
proved using the vertex as a constraint. This is done 
by considering the 2>N tra cks momentum components 
as additional parameters in the vertex fit. However 
the calculation of the constrained momenta and their 
correlations is CPU-consuming, and often only the fit- 
ted vertex position is needed. 

We could separate this step in a VertexSmoother 
component. It is run after fitting the vertex co- 
ordinates, using intermediate results cached into 
the VertexTrack objects. The user configures the 
VertexFitter so as to use this component or not. 



IV. VERTEX FINDING FRAMEWORK 

The variety of vertex finding algorithms that we 
currently explore is large and the decomposition 
of algorithms into components still evolves while new 
common features appear. We will thus not describe 
them, but rather focus on the evaluation and opti- 
mization tools. 



A. Evaluation 

1. Performance estimation 

We wish to compare the performance of the 
algorithms in finding the primary and secondary 
vertices, in producing ghost vertices from random 
track associations, and in assigning the tracks 
to their vertex efficiently and with a good pu- 
rity. The first 3 figures concern the vertex finding 
proper, and are evaluated by implementations of the 
VertexRecoPerf ormanceEstimator class. The last 2 
figures concern the assignment of tracks to vertices. 
They are computed by implementations of the 



Vert exTrackAssignmentPerf ormanceEstimator. 

These estimators are updated each event. 

2. Vertex selection and association 

The user needs to tell to these estimators which 
simulated vertices are important to reconstruct. A 
standard Filter is provided, which keeps only the 
simulated vertices for which at least 2 tracks were 
successfully reconstructed. This allows to study the 
algorithmic efficiency of vertex finding. 

The user also tells how to associate a simulated 
vertex to a reconstructed one. This is defined by a 
VertexAssociator. Association can be done by dis- 
tance or by tracks, counting the tracks common to the 
simulated and the reconstructed vertex. In standard 
tests the association is done by tracks. A simulated 
vertex is considered found if there is a reconstructed 
vertex with > 50% of its tracks originating from it. 
The association of the reconstructed and simulated 
tracks is performed by a TrackAssociator provided 
by the ORCA track analysis framework. 

B. Optimization 

Vertex finding algorithms have a few parameters 
that need to be tuned in order to get optimal per- 
formance for a given data set. Often, every physicist 
has to write his own code which scans the parameter 
range and finds the optimum parameter values. 

We propose a simple and elegant automatic tun- 
ing framework. The components of this frame- 
work are an abstract TunableVertexReconstructor, 
which interacts with a FineTuner object, and a 
special run controller which stops analysing events 
when the desired precision on the tuned parameters 
is reached. The TunableVertexReconstructor pro- 
vides the FineTuner with the initial range of param- 
eter values to be scanned. The FineTuner is an inter- 
face to an optimization engine. It maximises a Score, 
which is a function of the performance estimators con- 
figurable by the user: 

Score = {EffPV) a .{EffSV) b .{\ - FakeRatef... 

The user only has to re-implement the 
TunableVertexReconstructor for the concrete 
algorithm and parameters that are to be tuned. 
Currently the FineTuner implementation available is 
a ID maximizer, allowing to tune 1 parameter at a 
time. 

V. TESTS WITH CONTROLLED INPUT 

Parts of vertex reconstruction algorithms rely on 
models describing prior information. This informa- 
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tion is for example the event topology (size of beam 
spot, number of vertices,...) or the track parameter 
distributions (Gaussian resolution and pulls, tails...). 
Data often depart from these models, which affects 
the performance of the algorithms. 

To disentangle this from more intrinsic features of 
the algorithms, we have developed a simple Monte 
Carlo generator. It allows to simulate data in perfect 
agreement with the prior assumptions, or distorted in 
a controlled way. The number and position of the ver- 
tices, the number and momentum of the decay prongs, 
the track parameter resolutions and tails are defined 
by the user. 

This simulation takes O(10) ms per event, more 
than a thousand times faster than full event recon- 
struction. The time needed to perform most of the 
code debugging is reduced by the same factor. An- 
other important advantage is that most of the release 
tests of the vertex reconstruction code can be run in- 



dependently of the status of the reconstruction chain 
upstream. The simple Monte Carlo generator is cur- 
rently being interfaced with the CMS fast Monte Carlo 
simulation (FAMOS) [ill to account for track recon- 
struction effects in a more realistic way. 



VI. CONCLUSION 

We have developed an efficient and flexible class 
framework for the development of vertex fitting algo- 
rithms. It allows the coding of usual least-squares al- 
gorithms as well as robust ones. We provide a friendly 
environment for the evaluation and optimization of 
vertex finding algorithms. As shown at this confer- 
ence , the performance of the vertex fitters and find- 
ers tested for the CMS experiment are already close to 
matching the requirements for use online at the LHC. 
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